As enterprise computing environments become larger and more complex, so grows the difficulty of software deployment in those enterprise computing environments. Software deployment requires knowledge of the software and hardware environments of the underlying system, as well as compatibility issues that might arise between the deployable software and the existing environments. Accordingly, software developers attempt to provide users with a knowledge base for deploying and installing software according to previously-validated installation scenarios. However, the deployment rules defined in a conventional knowledge base often provide a very narrow and constrictive path for installing a specific component, because component developers have limited resources to validate the infinite possible environmental permutations in a customer system. As a result, software components are typically shipped with a single (or very few) possible installation scenarios, producing frequent installation deadlocks.
For example, a component that is about to be installed may require a specific resource. However, another component that is already installed in the system may require a different version of that same resource. Traditional deployment rules may be too limited, and dictate that these two components cannot be mutually installed on the same system. This behavior forces administrators to spend valuable time tinkering with installed components, guessing what will and will not work, and checking various permutations. Other frequent deployment problems arise when the software component builders, anticipating that their installation rules will be too constrictive, opt to define very generic rules that they are unable to test.
The problem is exacerbated in open source environments. Open source environments lends themselves very well to customization, for example, by changing Operating System (OS) functionality, adding middleware, adding third party applications, or installing proprietary products. However, that same benefit of customization is the source of challenges in creating a knowledge base for the deployment and maintenance of software components in these environments. The challenges of building a customized operating environment, implementing fixes, and installing proprietary and homegrown applications all require a deep and unique knowledge of the underlying OS that is typically not required in a proprietary operating environment (such as Windows), where the operating system vendor and software developers may execute software integrity tests and do not leave room for customizations. Windows is a trademark of Microsoft Corp. in the United States and other countries. All other company and product names may be trademarks of their respective companies.
To overcome these problems, a knowledge generation machine may be employed. The knowledge generation machine provides an automated method to build a knowledge base for collecting information about software and software environments, determining dependencies among software components, and generating deployment rules for the software. The knowledge generation machine collects knowledge from various sources, performs knowledge processing on the collected information, and produces a knowledge model. Using that knowledge model, a dependency model can be produced to allow for the generation of deployment rules for installing the software component in a computing environment.
One of the problems in knowledge processing is the scalability of converting mass amounts of information into relatively small amounts of formatted and related knowledge. For example, when a new OS is released, including versions for various hardware platforms, there may be gigabytes of code and associated information to process. Thus, there is a need for a knowledge generation machine that can scale to handle these large spikes in information, so that a knowledge base may be provided to customers quickly.
Another problem in collecting knowledge for a knowledge base for software dependency management is that the information can come from many sources. Though the software developer will provide a base of information about a software component, there is also information that is published about the software from other sources. Thus, there is a need to include this information to understand, correlate, and expand the dependency model in order to realize a complete set of the dependencies. Having the complete set of dependencies is an important factor as it directly affects the customer's adoption of the software solution.
Yet another problem of knowledge base generation is understanding and declaring the knowledge model a priori. Often this requires an evolutionary approach that relies on highly manual operations to extend the knowledge model and apply new logic to the knowledge model as it becomes available. This manual expansion means a delay before new information becomes available and is placed into the knowledge model. Accordingly, there is a need to provide a knowledge model that expands and adapts as new information is acquired, without the need for manual expansion.
Yet another problem in knowledge processing is the effect of knowledge processing segmentation on dependency resolution. Knowledge processing is often segmented upon traditional lines, e.g., by OS or by hardware version. This segmentation can cause a problem, however, when the dependency model for a software component includes unexpected dependencies between the element nodes that cause an irresolvable reference that should pass across the predefined segmentation. Often this irresolvable reference is left as an error state, but in software dependency management it is critical to maintain and manage this cross-segment dependency.